@jeremylong - ESAPI faced this simpler problem a while back. (E.g., see ESAPI discussion 768) Assuming that you still wish to continue to support the older Servlet API spec that uses the javax.servlet namespace, but depending on your circumstances, there may be a better way than making all these changes. (This approach if fine if you okay with abandoning your clients that are sill using the older Servlet API or want to maintain multiple forks or branches. We didn't want to do either for ESAPI.)

I played around with the Maven Shade plugin, but ruled that out as it created an uber jar that we didn't feel was acceptable. But then long story short, we ended up using the org.eclipse.transformer:transformer-maven-plugin plugin to just rewrite the byte-code. You can see details here in our pom and here in our README.

Now, given that you have Spring-Core 5.3.19 listed as a dependency in your jsp/pom.xml, this may not work for you, but I think it's certainly worth a shot. The ESAPI team is very happen with it and have heard no complaints yet about it. When we finally start on ESAPI 3, we will abandon support for the older Servlet API and only support the Jarkarta Servlet API 5.0 or later. But for now, we feel that we must support both of them. Of course, YMMV.

@kwwall I think you missed part of this PR - the legacy javax.servlet JAR will still be built and published. The only difference is that it will require at least Java 8 now - which shouldn't be a problem. A new jar will be produced that is Java 17 and uses the jakarta namespace for the servlet API.

Build passes - but fails on esapi thunk. Will be resolved with #76.

@jmanico any issues with these changes?